python/src/mcp_server/features/tasks/task_tools.py (4)

10-10: Import Literal for stronger type-safety on status.

Prepare for a Literal-typed status parameter in update_task.

-from typing import Any, Dict, List, Optional
+from typing import Any, Dict, List, Optional, Literal

---

305-313: Signature change LGTM; consider constraining status to allowed literals.

Using Literal reduces typos and improves mypy checks while remaining backward-compatible.

-        status: Optional[str] = None,
+        status: Optional[Literal["todo", "doing", "review", "done"]] = None,

---

339-357: Type the payload and simplify construction of update_fields.

Explicit typing helps mypy; the dict-comprehension reduces repetition and mistakes when new fields are added.

-            # Build update_fields dict from provided parameters
-            update_fields = {}
-            if title is not None:
-                update_fields["title"] = title
-            if description is not None:
-                update_fields["description"] = description
-            if status is not None:
-                update_fields["status"] = status
-            if assignee is not None:
-                update_fields["assignee"] = assignee
-            if task_order is not None:
-                update_fields["task_order"] = task_order
-            if feature is not None:
-                update_fields["feature"] = feature
-            if sources is not None:
-                update_fields["sources"] = sources
-            if code_examples is not None:
-                update_fields["code_examples"] = code_examples
+            # Build update_fields dict from provided parameters
+            update_fields: Dict[str, Any] = {
+                k: v
+                for k, v in {
+                    "title": title,
+                    "description": description,
+                    "status": status,
+                    "assignee": assignee,
+                    "task_order": task_order,
+                    "feature": feature,
+                    "sources": sources,
+                    "code_examples": code_examples,
+                }.items()
+                if v is not None
+            }

---

365-379: Consider accepting 204 No Content for robustness.

Some APIs return 204 for successful updates. Handling 200 and 204 avoids false negatives and reduces coupling to response shape.

-                response = await client.put(
-                    urljoin(api_url, f"/api/tasks/{task_id}"), json=update_fields
-                )
-
-                if response.status_code == 200:
-                    result = response.json()
-                    return json.dumps({
-                        "success": True,
-                        "task": result.get("task"),
-                        "message": result.get("message", "Task updated successfully"),
-                    })
+                response = await client.put(
+                    urljoin(api_url, f"/api/tasks/{task_id}"), json=update_fields
+                )
+
+                if response.status_code in (200, 204):
+                    if response.status_code == 204 or not response.content:
+                        return json.dumps({
+                            "success": True,
+                            "task": None,
+                            "message": "Task updated successfully",
+                        })
+                    result = response.json()
+                    return json.dumps({
+                        "success": True,
+                        "task": result.get("task"),
+                        "message": result.get("message", "Task updated successfully"),
+                    })

python/tests/mcp_server/features/tasks/test_task_tools.py (1)

185-204: Great coverage for no-fields guard; optionally assert no HTTP call is made.

You can also assert that PUT is never invoked in this path to harden the contract.

 @pytest.mark.asyncio
 async def test_update_task_no_fields(mock_mcp, mock_context):
     """Test updating task with no fields returns validation error."""
     register_task_tools(mock_mcp)
 
     # Get the update_task function
     update_task = mock_mcp._tools.get("update_task")
 
     assert update_task is not None, "update_task tool not registered"
 
-    # Call update_task with no optional fields
-    result = await update_task(mock_context, task_id="task-123")
+    # Call update_task with no optional fields
+    with patch("src.mcp_server.features.tasks.task_tools.httpx.AsyncClient") as mock_client:
+        mock_async_client = AsyncMock()
+        mock_client.return_value.__aenter__.return_value = mock_async_client
+        result = await update_task(mock_context, task_id="task-123")
 
     result_data = json.loads(result)
     assert result_data["success"] is False
     assert "error" in result_data
     assert isinstance(result_data["error"], dict)
     assert result_data["error"]["type"] == "validation_error"
     assert "No fields to update" in result_data["error"]["message"]
+
+    # Ensure we never attempted an HTTP call
+    mock_async_client.put.assert_not_called()

python/src/mcp_server/mcp_server.py (1)

216-221: Inline API snippet for update_task: list all supported fields for parity.

Minor nit: documenting all optional params avoids confusion and aligns with task_tools.update_task.

 - `update_task(task_id, title=None, status=None, assignee=None, ...)`
+ - `update_task(task_id, title=None, description=None, status=None, assignee=None, task_order=None, feature=None, sources=None, code_examples=None)`

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: CR
PR: coleam00/Archon#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-21T11:22:33.541Z
Learning: Applies to python/src/mcp/** : Keep MCP server implementation under python/src/mcp/

python/src/mcp_server/features/tasks/task_tools.py (1)

358-364: Good: early validation prevents accidental no-op updates.

This avoids confusing “successful” calls that don’t change anything and provides clear guidance to callers.

python/tests/mcp_server/features/tasks/test_task_tools.py (1)

171-172: LGTM: verifies payload fields for update_task.

Asserting the exact JSON sent (status, assignee) catches regressions in request construction.

Also applies to: 178-183

python/src/mcp_server/mcp_server.py (5)

195-199: Docs: Clear rule to use MCP tools for task management.

This addresses the root cause from #420 (wrong tool names) by steering clients to the correct surface.

---

206-214: Task Management Cycle reads well and matches exported tools.

The examples use get_task and update_task consistently with the implemented tool names.

---

245-249: Status flow guidance is consistent and actionable.

Matches the allowed status values used in task_tools.py.

---

239-243: Research tool availability verified

The functions perform_rag_query, search_code_examples, and get_available_sources are all implemented and decorated with @mcp.tool() in python/src/mcp_server/modules/rag_module.py. No further action is needed.

---

250-256: All Version Management Tools Properly Registered

I’ve confirmed that the four tools—create_version, list_versions, get_version, and restore_version—are defined in version_tools.py with @mcp.tool() and that register_version_tools is imported and invoked in mcp_server.py, with corresponding tests exercising each registration. No further changes are needed here.